\chapter{Fundamentals}

\section{Players in LBS}
When providing LBSs in the context of cellular networks it requires the
involvement of different players in order to provide the complete service.

Figure \ref{Overview players involved in LBSs.} depicts the parties. \textit{Location Based Services
Enabling Parties} are responsible for the whole deployment and maintenance of
LBSs. Location Based Services Enabling Parties are roughly divided into four 
categories:

\begin{figure}[h]
	\begin{center}
	    \includegraphics[width=12.35cm]{graphics/players}
		\caption[Overview players involved in LBSs.]{Overview of players involved in LBS \citep[p. 14]{GSMAssociation2003}.}
		\label{Overview players involved in LBSs.}
	\end{center}
\end{figure}

\begin{itemize}
  \item \textit	{Location Technology Providers} (LTP)\\
  				These are manufacturers of different hardware and software, which enable
  				positioning of mobile terminals. Moreover, these are vendors manufacturing
  				network
  				based and handset based positioning solutions. Some of the positioning
  				systems require specific capabilities both within the network and within
  				the mobile terminal. This leads to significant interoperability problems,
  				which need to be addressed.
  \item \textit {Network Operators} (NO)\\
  				These are companies that have infrastructure for \textit{Public Land
  				Mobile Network}s (PLMN).
  \item \textit {Regulators} (REG)\\
  				This party sets up laws, regulations etc., which give guidelines how LBSs
  				can be legally implemented. The major issue is likely to be privacy, with
  				both the \textit{European Union} (EU) and individual countries having their
  				own regulations, which will need to be followed.
  \newpage	
  \item \textit {Service Providers} (SP)\\
  These create and sometimes provide LBSs, which are used via NOs. SPs implement service logic and user interfaces. However, SPs do not necessarily have either data or infrastructure to offer LBSs to the customers.
\end{itemize}

\noindent
Another party are \textit{End-User}s, as depicted in figure
\ref{Overview players involved in LBSs.}. Generally End-Users are divided in two categories:

\begin{itemize}
  \item \textit{Targets} \\
  		These are End-Users whose position is asked by another End-User or by some service.
  \item \textit{Requestors} \\
  		These are End-Users who ask for the position of some service or another End-User.
\end{itemize}

\noindent
End-Users can simultaneously have both roles. Further information can be found in Location Based Services \citet{GSMAssociation2003}.

\section{Types of LBS}
End-Users can either demand information for their position 
themselves or secondly a LBS application or another End-User can request location
dependent information of other users. These different actions introduce
three LBS application types \citep{GSMAssociation2003}:

\begin{itemize}
  \item \textit	{Pull-services} \\
  				In this case a customer makes by himself a request for a LBS. The customer
  				gives admission to locate himself or herself in order to complete the LBS request.  
  \item \textit	{Push-services} \\
  				This type of LBS imply that the customer entitles the SP to locate
  				himself or herself for the purpose of sending location specific information
  				from  the SP to the End-User. The request is technically made by the 
  				Service-Provider and not from the End-User in comparison to Pull-services.
  \item \textit	{Tracking-services} \\
				The idea of this type of service is, that someone (person or service) asks
				for a location of the mobile terminal (person, vehicle, fleet etc.). As in
				the pull and push cases the assumption is that the customer has given
				permission which allows particular persons or services to track him.
\end{itemize}

\section{APIs and Protocols}
As presented previously, different parties are involved when providing LBSs. Furthermore various LBS types demand more flexibility on the application architecture and their interfaces. ``Carriers want LBS platforms that provide application programming interfaces (APIs) that can connect multiple devices to their choice of accurate, up-to-date, and comprehensive map content, reliable  \textit{Location Engines}, and other services'' \citep[p. 152]{SchillerVoisard2004}.

\noindent
Today's LBSs are tightly coupled to PLMN infrastructures. Spiekermann \citep{SchillerVoisard2004} states, that emergency services had turned out to be an important application in the context of LBSs. When analysing this application, close coupling to PLMN operators is indispensable because of high accuracy requirements regarding the positioning, as illustrated in table \ref{services}.  Moreover, these services require high interoperability and roaming abilities. 

\par
\begingroup
\leftskip=0.5cm
\rightskip=0.7cm
\noindent
\textit{
However, present LBSs are to a large extent incompatible with each other and unable to interoperate on location semantics. They are mostly bound to a specific technology reflecting the preferences of the service provider} \citep{IbachHorbank2004}.
\par
\endgroup
\noindent

\begin{table}[h]
\caption{Overview of LBS applications and level of accuracy required \citep{SchillerVoisard2004}.
According to \cite{ZeimpekisGiaglisLekakos2001}, accuracy levels are defined as follows: high \(<\) 100 meters, medium 100-250 meters and low \(>\) 250 meters} 

\begin{tabular}{ll}
\\
%
\textbf{Application}&
\textbf{Accuracy}\\ \hline
%
News &
Low &
%
Directions &
High &
%
Traffic Information &
Low &
%
Point of Interest &
Medium to High &
%
Yellow Pages &
Medium to Low &
%
Car Navigation &
Medium to High &
%
Personal Navigation &
High &
%
Directory Assistance &
Medium to High &
%
Fleet Management &
Low &
%
Car Tracking &
High &
%
Asset Tracking &
High &
%
Gaming &
Medium &
%
M-Commerce &
Medium to High &
%
Emergency &
High &
%
Sensitive Goods Transportation &
High &
%
Child Tracking &
Medium to High &
%
Pet Tracking &
Medium to High &
%
Electronic Toll Collection &
Medium to High &
%
Public Management System &
Medium to High &
%
Remote Workforce Management &
Low &
%
Local Advertisement &
Medium to High &
%
Location-Sensitive Billing &
Medium to Low & \hline
%
\end{tabular}
\label{services}
\end{table}

The standardisation of APIs and protocols in the context of LBSs is in early stage. A few interest groups try to find common consent regarding this matter. There are four APIs to get positioning information from a network today. Further details on these approaches can be found in the following sections.

\subsection{Location Interoperability Forum (LIF) API}
The LIF was set up in 2000. It addresses the question of how application servers could address different \textit{Mobile Positioning Centers} (MPC) or work directly with a \textit{Home Location Register} (HLR) of a PLMN operator. The LIF has produced a specification for a \textit{Mobile Location Protocol} (MLP), which is an application-level protocol for the positioning of MTs. ``It is independent of the underlying network technology (and thus, of the positioning method)'' \citep[p. 67]{Hjelm2002}.\\
As depicted in figure \ref{Overview of LIF architecture.} MLP serves as an interface between \textit{Location Server}, integrated into the PLMN infrastructure, and  \textit{Location Enabling Server}. This architecture distinguishes from others primarily by its interoperability and roaming functionalities. The \textit{Location Enabling Server} (LES) can be seen as the application server from the SP. This server implements the business logic of the LBS application. Further information about the LIF architecture can be found in Location Based Services
\citep{GSMAssociation2003}.
  				
\begin{figure}[h]
\begin{center}
\includegraphics[width=12.35cm] {graphics/lif}
\caption[Overview of LIF architecture.]{Overview of LIF architecture \citep[p. 162]{SchillerVoisard2004}.}
\label{Overview of LIF architecture.}
\end{center}
\end{figure}
  				
\subsection{Wireless Application Protocol (WAP) API}
Similar to the LIF architecture the WAP Forum has developed a location architecture to fit into WAP that interacts with MPCc and application servers. ``The WAP Location Framework overlaps the LIF API in many ways, and while that is partly intended for communication from a mobile station directly to the MPC''  \citep[p. 77]{Hjelm2002}. Another aspect comparing to the LIF API is, that the system also integrates the WAP 2.0 Push system, enabling information to be pushed to clients (using HTTP, you can only pull information) \citep{Hjelm2002}. In addition the \textit{Location Attachment Service} (LAS) way of using the WAP API gives the possibility to add semantics into a user request. ``When a user sends a request to a service and the information can be personalised based on the position, it is very convenient to include the location of the user in the request so that the response can be returned within the scope of the same transaction'' \citep{Hjelm2002}. As \citeauthor{Hjelm2002} states,  this API is more constraint and attempts to address all the needs in the context of mobile environments.
  				
\subsection{Parlay API}
The LIF and WAP Forum architectures borrow many ideas form the Parlay architecture. In comparison to the LIF and WAP architecture which uses XML based protocols on the level of HTTP, Parlay uses \textit{Common Object Request Broker} (CORBA). Furthermore CORBA interfaces are based on the \textit{Interface Definition Language} (IDL). Hence, type safety between communication instances is one positive side-effect of this approach. 

\par
\begingroup
\leftskip=0.5cm
\rightskip=0.7cm
\noindent
\textit{
Parlay gives programmers more control than the LIF and WAP Forum APIs over how position information is retrieved, and what position information will be retrieved, for applications that rely on the network. This scenario means that for applications that use the network more frequently, such as tracking applications, Parlay might be a better choice (if available and not overpriced)} \citep[p. 87]{Hjelm2002}.
\par
\endgroup
\noindent
			
\subsection{Magic API}
The goal of this architecture is creating a \textit{Webservices} (WSs) API for location information in the context of automotive industry. \textit{Simple Object Access Protocol} (SOAP) is used to communicate between the mobile station and the server. It is worth mentioning, that this architecture is planned for monolithic data delivery. All the data and applications can be deployed on CD. The architecture also supports thin client or fat client architecture because of its object oriented approach. ``They also position themselves one step higher up in the value chain than the LIF, WAP Forum, and Parlay APIs, which means that their niche is somewhat different - not companies who primarily want the information, but companies who want to provide services based on the information'' \citep[p. 94]{Hjelm2002}.

More information on LBS API's can be found in Creating Location Services for the Wireless Web \citep{Hjelm2002}. To compare the presented APIs the following table \ref{architectureDifferences} lists some key differences between these approaches.

\begin{table}[h]
\caption{Differences LBS architectures.}
\begin{tabular}{lllll}
%
\\
&
\textbf{LIF}&
\textbf{WAP}&
\textbf{Parlay}&
\textbf{Magic}\\ \hline
%
Communication &
XML &
XML &
CORBA &
SOAP &
%
Coupling &
Closely &
Closely &
Closely &
Loosely &
%
Usage &
Standard &
Sometimes &
Standard &
Low &
%
Monolithic deployment &
No &
No &
No &
Yes &
%
Client architecture &
Thin &
Thin &
Thin &
Fat or Thin & \hline
%
\end{tabular}
\label{architectureDifferences}
\end{table}

\section{Privacy Principles}
``Privacy is the claim of individuals, groups, or institutions to determine for
themselves when, how, and to what extent information about them is communicated
to others'' \citep{Westin1970}. Bringing this statement in conjunction with LBSs, it
can be interpreted in very different ways, depending on the local legal system,
the practice of it, and the user's preconception.

\par
\begingroup
\leftskip=0.5cm
\rightskip=0.7cm
\noindent
\textit{
Personalization, especially combined with location data and logging by the
service provider, has the potential to be extremely contentious. The line is fine, and users are willing to give up quite a
great deal of privacy in the interest of convenience} \citep[p. 309]{Hjelm2002}.
\par
\endgroup
\noindent

\noindent
``As a result of this potential threat, the EU Commission has recognized the issue in its Directive on Privacy and Electronic Communications (Directive 2002/58/EC)'' \cite[p. 17]{SchillerVoisard2004}.

\noindent
Main points covered in the directive (Article 9) \citep{DirectiveEU2002} are as
follows:

\begin{itemize}
  \item Location data may only be processed when it is made anonymous or with
  the consent of the user for the duration necessary for the provision of a
  service.
  \item The location service must \textbf{inform} the user, \textbf{prior} to obtaining their
  consent, of the type of location data that will be processed, of the \textbf{purpose}
  and \textbf{duration} of the processing, and whether the data will be transmitted to a
  third party.
  \item Users shall be given the possibility to withdraw their consent for the
  processing of location data at any time.
  \item Users must have \textbf{simple means, free of charge} for temporarily refusing
  the processing of location data \textbf{for each connection to the network}.
\end{itemize}

Comparing the situation with the United States the handling of location
dependent, personal information in the EU is part of the
data protection law, which
regulates privacy of information. In the U.S. several industry groups affect the
privacy issue. Further information in this regard can be looked up in Creating Location Services for the Wireless Web 
\citet[p. 309]{Hjelm2002}. One example thereby is Vodafone. \citet{SchillerVoisard2004} state, that their middleware products pay
particular attention in privacy functionality. As a result of industry pressure,
Vodafone is establishing and driving privacy standards into the mobile industry
that correspond to Fair Information Practices, as they have been proposed by
the U.S. \textit{Federal Trade Commision} (FTC). The guidelines are as follows 
\citep{SchillerVoisard2004}:
\begin{itemize}
  \item Explict and written capture of consent of the locatee
  \item Clear information of the locatee of the nature of the locator
  \textit{prior  to consent} 
  \begin{itemize}
    \item Name and mobile number of the locator
    \item Web site or customer support where further service information, terms,
    and conditions of the locator can be accessed
    \item Service name and service provider
    \item An exact description of the service
    \item Information on the duration and frequency of the location requests as
    well as circumstance
  \end{itemize}
  \item Explicit and repeated notification of location request happening
  \item Direct access of the locatee to a site that specifies who has the right
  to position oneself
  \item A direct and easy way to cancel a passive service
\end{itemize}

These guidelines stated above give users the chance to check the location
service's credentials. Consequently the user is informed by any aspect of data
handling. ``Users, it seems, are willing to trust service providers if they feel
that the information given to them is truthful about how the information will be
used'' \citep[p. 322]{Hjelm2002}.

\section{Summary}
This chapter presents the parties involved in LBSs. Subsequently, it lists different types of LBSs. Furthermore this chapter gives a classification of LBS architectures. It introduces the LIF architecture among others. The LIF architecture is distinguished from others by its interoperability and roaming features. This architecture is in widespread use nowadays and requires close coupling to PLMN operators. Nevertheless loosely coupled LBS architectures, like the Magic architecture, exist, but are not often used. Ending with privacy principles this chapter introduces into LBSs.